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REMARKS 

Claims 1-34 are pending and are rejected. Claims 1, 10, 11, 19, 21 and 22 are 
amended. New Claims 35-38 are added. Reconsideration and allowance of Claims 1- 
38 are respectfully requested. 

Objections to Drawings 

The drawings are objected to. In response thereto, Applicants submit a set of 
replacement (e.g., formal) drawings in compliance with 37 CFR 1.84, which are 
attached hereto under separate cover. No new matter is introduced. 

Amendments to Specification 

Applicants amend paragraph [0065] to correct a clerical error, and amend 
paragraph [0033] to include updated status information for a referenced U.S. Patent 
Application. No new matter is introduced. 

Claim Amendments 

Claims 10, 11, 19, and 21 are amended to correct clerical errors. 

Claims 1 and 22 are amended to clarify that which the Applicants regard as the 
invention. Support for the amendment of Claims 1 and 22 may be found in Applicants' 
specification at paragraph [0081]. No new matter is introduced. 

Claim Rejections under 35 USC §102 over Blake 

Claims 1, 9-10, 22-26, and 31-32 are rejected under 35 USC §102(b) as being 
anticipated by Blake et al, "An Architecture for Differentiated Services," RFC 2475, 
December 1998, hereinafter referred to as Blake. Applicants respectfully traverses 
these rejections. 

Independent Claim 1 

Applicants' Claim 1 recites (as amended): 

A traffic management processor for processing a plurality of different traffic 
flows on a per-flow basis, each traffic flow including any number of packets each 
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including a flow identification (ID) indicating to which traffic flow the packet belongs, 
comprising: 

means for tracking each packet according to its flow ID; and 
means for scheduling each packet according to its flow ID. 

Blake fails to disclose or suggest a traffic management processor that 
processes different traffic flows on a per-flow basis, as recited in Applicants' Claim 1. 

Applicants' Claim 1 recites a traffic management processor that processes 
different traffic flows on a per-flow basis by tracking and scheduling each packet 
according to its flow ID, where the flow ID indicates which traffic flow the packet 
belongs to. In contrast, Blake discloses a traffic routing architecture that processes 
aggregated traffic by "applying per-hop behaviors to aggregates of traffic which have 
been appropriately marked using the DS field in the [packet] headers." 1 Thus, for 
Blake's architecture, a packet's DS codepoint identifies a behavior aggregate or traffic 
type, NOT the particular traffic flow to which the packet belongs. 2 Indeed, Blake 
specifically states that "per-application flow or per-customer forwarding state need not 
be maintained within the core of the network," 3 and therefore seems to teach away 
from the per-flow management process recited in Applicants' Claim 1 . 

The Office Action states that Blake discloses "a traffic management processor 
(Figure 1 , page 16) for processing a plurality of different traffic flows, each traffic flow 
including any number of packets each including a flow ID (DS codepoint in page 4) 
indicating to which traffic flow the packet belongs, comprising: means for tracking each 
packet (Classifier in Figure 1, page 16) according to its flow ID (DS codepoint in page 
4); and means for scheduling each packet (Traffic conditioner, page 7, in view of 
Figure 1 in page 16) according to its flow ID (DS codepoint in page 4)." Applicants 
disagree. 

First, the Office Action seems to equate Blake's "DS codepoint" with the flow ID 



1 See Blake, page 3, second paragraph. 

2 See Blake, page 12, section 2, which provides: "Each behavior aggregate is identified 
by a single DS codepoint. Within the core of the network, packets are forwarded according to 
the per-hop behavior associated with the DS codepoint." 

3 See Blake, page 3, second paragraph. 
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recited in Applicants' Claim 1. However, while the flow ID recited in Applicants' Claim 1 

indicates which traffic flow a corresponding packet belong to, Blake's DS codepoint is 

used to assign packets to a particular traffic type (e.g., to a particular traffic behavior 

aggregate). Indeed, Blake specifically states that the DS codepoint is used to select a 

per-hop behavior (PHB), 4 which is "the externally observable forwarding behavior 

applied at a DS-compliant node to a DS behavior aggregate." 5 Thus, in contrast to the 

flow ID of Applicants' Claim 1 , Blake's DS codepoint does NOT indicate which traffic 

flow the packet belongs to, but instead the DS codepoint is a value that can be used to 

assign the packet to a particular traffic behavioral aggregate. 

Second, the Office Action seems to equate Blake's "classifier" with the "means 

for tracking each packet" recited in Applicants' Claim 1 . However, while the "means for 

tracking" recited in Applicants' Claim 1 tracks each packet according to its flow ID (and 

thus according to the packet's traffic flow), Blake's classifier simply "steers the packets 

to a logical instance of a traffic conditioner." 6 Accordingly, Blake's classifier does NOT 

track packets on a per-flow basis according to flow ID, as recited in Applicants' Claim 

1. 

Third, the Office Action seems to equate Blake's "traffic conditioner" with the 
"means for scheduling each packet" recited in Applicants' Claim 1. However, while the 
"means for scheduling" recited in Applicants' Claim 1 schedules each packet according 
to its flow ID (and thus according to the packet's traffic flow), Blake's traffic conditioner 
performs shaping and policing functions on aggregated traffic according to traffic type 
or behavior. More specifically, Blake's traffic conditioner changes the DS codepoint of 
a packet according to its traffic type so that the packet is added to the corresponding 
behavior aggregate. 7 Blake further provides that "when packets exit the traffic 
conditioner of a DS boundary node the DS codepoint of each packet must be set to an 



4 See Blake, page 4 (definition of "DS codepoint"). 

5 See Blake, page 6 (definition of "PHB"). 

6 See Blake, page 15, section 2.3.3. 

7 See Blake at page 16, section 2.3.3.2, which provides: Packet marker set the DS field 
of a packet to a particular codepoint, adding the marked packet to a particular DS behavior 
aggregate. The marker may be configured to mark all packets which are steered to it to a 
single codepoint, or may be configured to mark a packet to one of a set of codepoints used to 
select a PHB in a PHB group." 
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appropriate value." 8 Accordingly, Blake's traffic conditioner does NOT schedule each 
packet according to its flow ID, as recited in Applicants' Claim 1. 

To anticipate a claim under 35 USC §102, each and every element of the claim 
must be disclosed in a single reference 9 . The exclusion of a claimed element from a 
prior art reference is typically enough to negate anticipation under 35 USC §102. Thus, 
because Blake fails to disclose or suggest a traffic management processor including 
"means for tracking each packet according to its flow ID" and "means for scheduling 
each packet according to its flow ID," as recited in Applicants' Claim 1, Claim 1 is not 
anticipated by Blake. Accordingly, Applicants respectfully request the Office to 
withdraw the rejection of Claim 1 . 

Claims 2-1 1 depend from Claim 1 and therefore distinguish over the cited 
references for at least the same reasons as Claim 1 . 

Independent Claim 22 

Applicants' Claim 22 recites (as amended): 

A method for processing a number of traffic flows on a per-flow basis, each 
including one or more packets, comprising: 
receiving an incoming packet; 

determining which traffic flow the incoming packet belongs to; and 
scheduling the incoming packet for departure according to which traffic flow the 
packet belongs. 

Blake does not disclose or suggest a method for processing a number of traffic 
flows on a per-flow basis, as recited in Applicants' Claim 22. 

The Office Action states that Blake discloses "determining which traffic flow the 
incoming packet belongs to" (Classifier in Fig 1, page 16) and "scheduling the 
incoming packet for departure according to which traffic flow the packet belongs" 
(Meter and Marker in Fig 1, Page 16). Applicants disagree. 

First, as discussed above with respect to Claim 1 , Blake's traffic classifier 



8 See Blake, page 16, section 2.3.3. 

9 Corning Glass Works v. Sumitomo Electric . 9 USPQ2d 1962, 1965 (Fed. Cir. 1989). 
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simply "steers the packets to a logical instance of a traffic conditioner." Blake's traffic 
classifier does NOT determine which traffic flow a packet belongs to, nor has the 
Office Action pointed to any such language in Blake that discloses "determining which 
traffic flow the incoming packet belongs to," as recited in Applicants' Claim 22. Indeed, 
as discussed above, Blake teaches processing aggregated traffic, and specifically 
discourages per-flow traffic management. 

Second, as discussed above with respect to Claim 1 , Blake's traffic conditioner, 
which includes the "meter" and "marker" cited by the Office Action, performs shaping 
and policing functions on aggregated traffic according to traffic type or behavior, NOT 
according to each packet's traffic flow. Thus, while the method of Applicants' Claim 22 
schedules packets for departure according to which traffic flow the packets belong to, 
Blake's traffic conditioner changes the DS codepoint of a packet according to its traffic 
type so that the packet is added to the corresponding behavior aggregate. 

Accordingly, because Blake does not disclose or suggest "determining which 
traffic flow the incoming packet belongs to" and "scheduling the incoming packet for 
departure according to which traffic flow the packet belongs," as recited in Applicants' 
Claim 22, Claim 22 is patentable over Blake. 

Claims 23-34 depend from Claim 1 and therefore distinguish over the cited 
references for at least the same reasons as Claim 1 . 

Claim Rejections under 35 USC 5102 over Ohqane 

Claims 12-21 are rejected under 35 USC §1 02(b) as being anticipated by 
Ohgane (USP 5,875,173). Applicants respectfully traverses these rejections. 

Independent Claim 12 

Applicants' Claim 12 recites: 

A traffic management processor for managing a number of traffic flows each 
including one or more packets, comprising: 

a content address memory (CAM) device having a plurality of rows, each row 
storing a flow identification (ID) for a corresponding packet, the flow ID indicating to 
which traffic flow the packet belongs; 
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a departure time table including a plurality of rows, each coupled to a 
corresponding row of the CAM device and configured to store a departure time for the 
corresponding packet; and 

compare logic having inputs coupled to corresponding rows of the departure 
time table, the compare logic for comparing the departure times with each other to 
determine which departure time is the earliest. 

Ohgane fails to disclose or suggest the traffic management processor of 
Applicants' Claim 12. 

The Office Action seems to equate the Figure 6 table of Ohgane's control 
memory 27 with the CAM device recited in Applicants' Claim 12. However, each row of 
the CAM of Applicants' Claim 12 stores "a flow ID" that indicates which traffic flow a 
corresponding packet belongs to. In contrast, Ohgane's table of Figure 6 is merely a 
table; it is NOT a CAM that is capable of comparing its contents with an input data or 
search key. Indeed, there is no language in Ohgane that discloses or suggests that the 
table of Figure 6 is a CAM, as recited in Applicants' Claim 12. Further, Ohgane's table 
of Figure 6 stores "a peak rate (Tp), a current CAM set value (Ts), the number N of 
sent ATM cells, a cell_sent flag representing whether an ATM cell in question is sent 
or not, a cell header and an RM cell payload per virtual channel VC." 10 As known in the 
art and described in Ohgane, a virtual channel is a time-multiplexed signal path across 
an ATM network through which packets are transmitted. Therefore, the virtual channel 
of Ohgane is NOT a flow ID that indicates which traffic flow a packet belongs to. 
Accordingly, Ohgane does not disclose or suggest a CAM "having a plurality of rows, 
each row storing a flow identification (ID) for a corresponding packet," as recited in 
Claim 12. 

Further, the Office Action seems to equate the decoder 512, mode switching 
circuit 515, and selector 516 of Ohgane's CAM 51 with the compare logic recited in 
Applicants' Claim 12. However, Ohgane's decoder 512, mode switching circuit 515, 
and selector 516 do NOT compare any values, but rather control the operation of 
Ohgane's CAM array 51 1 , which as noted by the Office Action stores packet 

10 Ohgane, col. 8, lines 63-67. 
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transmission times (T). More specifically, decoder 512 selects rows of CAM array 51 1 
for read and write operations, while mode switching circuit 515 and selector 516 
together select the source of input data provided to CAM array 51 1 . Further, the 
transmission times (T) stored in Ohgane's CAM array 51 1 are compared with an input 
value (e.g., provided by counter 50); they are NOT compared with each other, as 
recited in Applicants' Claim 12. Indeed, the portion of Ohgane cited by the Office 
Action provides "When this time value (T) matches with a value identified by the 
counter 50, an address where this time value (T) is stored can be determined as a 
virtual channel VC for the next cell to be transmitted." 11 Thus, Ohgane does NOT 
disclose or suggest "compare logic having inputs coupled to corresponding rows of the 
departure time table, the compare logic for comparing the departure times with each 
other to determine which departure time is the earliest," as recited in Applicants' Claim 
12, nor has the Office Action pointed to any such language. 

Accordingly, because Ohgane does not disclose or suggest "a content address 
memory (CAM) device having a plurality of rows, each row storing a flow identification 
(ID) for a corresponding packet, the flow ID indicating to which traffic flow the packet 
belongs" or "compare logic having inputs coupled to corresponding rows of the 
departure time table, the compare logic for comparing the departure times with each 
other to determine which departure time is the earliest," as recited in Applicants' Claim 
12, Claim 12 is patentable over Ohgane. 

Claims 13-21 depend from Claim 12 and therefore distinguish over the cited 
references for at least the same reasons as Claim 12. 

Claim Rejections under 35 USC 5103 

Claims 2-8, 27-30, and 33-34 are rejected under 35 USC §1 03(a) as being 
unpatentable over Blake in view of Ohgane. Applicants respectfully traverse these 
rejections. 

Claims 2-8 depend from Claim 1 and therefore distinguish over the cited 
references for at least the same reasons as Claim 1 . 

Claims 27-30 and 33-34 depend from Claim 22 and therefore distinguish over 

11 Ohgane, col. 8, lines 19-22. 
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the cited references for at least the same reasons as Claim 22. 
New Claims 35-38 

Claim 35 depends from Claim 1 and therefore distinguishes over the cited 
references for at least the same reasons as Claim 1 . 

Claims 36-37 depend from Claim 12 and therefore distinguish over the cited 
references for at least the same reasons as Claim 12. 

Claim 38 depends from Claim 22 and therefore distinguishes over the cited 
references for at least the same reasons as Claim 22. 

Support for new Claims 35-36 and 38 may be found in Applicants' specification 
at paragraph [0095], and support for new Claim 37 may be found in Applicants' 
specification at paragraph [0081]. No new matter is introduced. 
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CONCLUSION 

In light of the above remarks, it is believed that Claims 1-38 are in condition for 
allowance and, therefore, a Notice of Allowance of 1-38 is respectfully requested. If the 
Examiner's next action is other than allowance as requested, the Examiner is 
requested to call the undersigned at (408) 236-6646. 



Respectfully submitted, 



William L Paradice III 
Dated Attorney for Applicant 

Reg. No. 38,990 
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